Web browser programs, such as Mozilla Firefox, are commonly used to request web pages and/or other resources from remote web servers. As used herein, a “web page” is a file or document that is processed by a web browser. Typically, a web browser makes such a request by sending a Hypertext Transfer Protocol (HTTP) request toward a remote web server. The HTTP request may be transmitted across several networks, including the Internet, before the request reaches the intended web server.
Upon receiving an HTTP request, a web server typically locates a web page that is identified by a Uniform Resource Locator (URL) specified in the HTTP request. The web server generates an HTTP response that comprises the identified web page, and then sends the HTTP response toward the web browser program. Like the HTTP request, the HTTP response may travel over several networks before reaching its destination.
Typically, when the web browser receives the HTTP response, the web browser interprets the web page that is contained therein and displays, to the web browser's user, content that the web page represents. Such content may include text and images, for example.
Sometimes, the web page comprises a form. A form typically comprises one or more user interface elements through which a web browser's user can select or input data that is to be sent to the web server. Such user interface elements may include text entry fields, drop-down menus, checkboxes, and radio buttons, for example. The source code of the web page may express the user interface elements as tags in Hypertext Markup Language (HTML), for example.
Such a form usually also comprises a user interface element that, when activated by a user, causes the web browser to send the user-inputted form data toward the web server. Usually, this user interface element is a “submit” button control. Typically, in response to a user's activation of the “submit” button control, the web browser generates another HTTP request and sends that HTTP request toward the web server. For each user interface element in the form, the HTTP request specifies the data that the user inputted or selected via that user interface element.
For example, a form might contain separate text entry fields for a user's first name, a user's last name, a user's phone number, and a user's zip code. If the user enters data into each of these text entry fields and then clicks on the “submit” button control in the form, then the user's web browser responsively generates an HTTP request that indicates the user-entered data for each text entry field, and sends the HTTP request toward a web server—usually, the web server from which the form originated.
When the web server receives an HTTP request that contains user-entered data submitted through a form, the web server may execute a program that is designed to handle the data. For example, such a program may create a database record in a database and store the data in the database record.
In some cases, before such a program performs specified operations relative to the data, such as storing the data in a database, the program needs to validate the data. As used herein, “validating” data means determining whether the data satisfy programmer-specified criteria. If the data satisfy the specified criteria, then the data are valid. Alternatively, if the data fail to satisfy the specified criteria, then the data are invalid. Usually, if the data are invalid, then the program needs to make this fact known to the user who entered the data, and give the user another opportunity to enter valid data.
For example, if a program executing on a web server receives user-entered data that corresponds to a text entry field for a zip code, then the program may validate the data by determining whether the data comprise only digits, and whether the data comprise exactly five digits. If the data for the zip code field comprise non-digit characters or more or less than five digits, then the program needs to inform the user why the data he entered into the zip code field is invalid, and provide the user with an opportunity to enter valid data into the zip code field.
Typically, a program executing on a web server attempts to remedy the receipt of invalid user-entered data by generating a new web page and sending the new web page within an HTTP response toward the web browser. Usually, the new web page contains a form that is similar to the form that the web server previously sent to the web browser. One or more user interface elements of the form might already indicate the data that the user previously selected or entered, so that the user is not required to fill out the entire form again. Alternatively, the form might omit user interface elements through which the user previously entered or selected valid data.
Additionally, the new web page usually contains an admonition to the user. The admonition usually tells the user specifically what was wrong with the data that the user previously entered or selected. For example, if the user entered only four digits into a zip code field, then the admonition may tell the user that the contents of the zip code field must be exactly five digits.
After generating the new web page, the program executing on the web server sends the new web page toward the web browser in an HTTP response. Upon receiving the HTTP response, the web browser interprets the new web page that is contained therein and displays, to the web browser's user, the content that the web page represents, including the form and the admonition as described above. The user then has the opportunity to submit valid data to the web server through the form.
The validation process described above requires a “page refresh.” That is, the validation process described above requires the web browser to send all of the user-entered form data to the web server in an HTTP request, and requires a program executing on the web server to generate and send a complete, new web page to the web browser in an HTTP response if any of the user-entered form data are invalid.
As most users of web browsers know, the time required for an HTTP request to travel from a web browser to a web server, and the time required for an HTTP response to travel from the web server to the web browser, can be agonizingly long. This is colloquially known as a “round trip.” Between the time that a user submits a “submit” button control and the time that the web browser tells him that some of his data is invalid, the user often can only wait. If the web page contained in the HTTP response includes large images, then the time required to send the HTTP response from the web browser to the web server can be significant.
Some validation approaches attempt to avoid the delays that attend a page refresh by validating user-entered data at the client program (i.e., the web browser) rather than the remote web server, thereby avoiding the round trip entirely. For example, according to one approach, a web page that contains a “blank” form also comprises hidden instructions that the web browser executes in response to the occurrence of a specified event relative to a specified user interface element of the form. This practice is known as client-side validation. Such instructions are often written using JavaScript, for example.
For example, the code of the web page that the web server originally sends toward the web browser might comprise instructions that the web browser executes in response to a text field losing focus, for example (a particular user interface element “loses focus” when a user selects or activates a different user interface element after the user most recently selected or activated the particular user interface element). When executed, the instructions might cause the web browser to determine whether the data entered into the zip code field comprise exactly five digits. The instructions might cause the web browser to display a “pop-up” window, containing an admonition, if the data entered into the zip code field are invalid.
Such an approach is useful in cases where validation is simple and can be expressed through web browser-executable instructions. However, not all validation can be performed on the client side. In some cases, a determination of the validity of user-entered data can only be made by comparing the data to other data that is stored only at the web server, for example. For example, a database at the web server might contain a username and associated password that need to be retrieved before the validity of the user-entered data can be determined. It would not be practical to send the entire contents of the database to the client. For another example, considering the zip code example above, zip code validation is better performed at the server side than the client side. Using server-side validation, a server-side database could be consulted to determine whether a client-submitted zip code actually is a real zip code.
Therefore, a technique for validating user-entered data at a web server without inducing a page refresh would be both useful and desirable.